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Abstract 


When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network, the Multiprotocol Label 
Switching (MPLS) TE Label Switched Path (LSP) infrastructure may be duplicated, even if the 
destination IPv4 and IPv6 addresses belong to the same remote router. In order to achieve an 
integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels 
created using information propagated in another OSPF instance. This issue is solved by 
advertising cross-address family (X-AF) OSPF TE information. 


This document describes an update to RFC 5786 that allows for the easy identification of a 
router's local X-AF IP addresses. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc8687. 


Copyright Notice 


Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights 
reserved. 
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This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
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provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


TE extensions to OSPFv2 [RFC3630] and OSPFv3 [RFC5329] have been described to support intra- 
area TE in IPv4 and IPv6 networks, respectively. In both cases, the TE database provides a tight 
coupling between the routed protocol and advertised TE signaling information. In other words, 
any use of the TE database is limited to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 
[RFC5340]. 


In a dual-stack network, it may be desirable to set up common MPLS TE LSPs to carry traffic 
destined to addresses from different address families on a router. The use of common LSPs eases 
potential scalability and management concerns by halving the number of LSPs in the network. 
Besides, it allows operators to group traffic based on business characteristics, class of service, 
and/or applications; the operators are not constrained by the network protocol used. 


For example, an LSP created based on MPLS TE information propagated by an OSPFv2 instance 
can be used to transport both IPv4 and IPv6 traffic, as opposed to using both OSPFv2 and OSPFv3 
to provision a separate LSP for each address family. Even if, in some cases, the address-family- 
specific traffic is to be separated, calculation from a common TE database may prove to be 
operationally beneficial. 
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During the SPF calculation on the TE tunnel head-end router, OSPF computes shortcut routes 
using TE tunnels. A commonly used algorithm for computing shortcuts is defined in [RFC3906]. 
For that or any similar algorithm to work with a common MPLS TE infrastructure in a dual-stack 
network, a requirement is to reliably map the X-AF addresses to the corresponding tail-end 
router. This mapping is a challenge because the Link State Advertisements (LSAs) containing the 
routing information are carried in one OSPF instance, while the TE calculations may be done 
using a TE database from a different OSPF instance. 


A simple solution to this problem is to rely on the Router ID to identify a node in the 
corresponding OSPFv2 and OSPFv3 Link State Databases (LSDBs). This solution would mandate 
both instances on the same router to be configured with the same Router ID. However, relying on 
the correctness of configuration puts additional burden and cost on the operation of the network. 
The network becomes even more difficult to manage if OSPFv2 and OSPFv3 topologies do not 
match exactly, for example, if area borders are chosen differently in the two protocols. Also, if 
the routing processes do fall out of sync (e.g., having different Router IDs for local administrative 
reasons), there is no defined way for other routers to discover such misalignment and to take 
corrective measures (such as to avoid routing traffic through affected TE tunnels or alerting the 
network administrators). The use of misaligned Router IDs may result in delivering the traffic to 
the wrong tail-end router, which could lead to suboptimal routing or even traffic loops. 


This document describes an update to [RFC5786] that allows for the easy identification of a 
router's local X-AF IP addresses. [RFC5786] defined the Node IPv4 Local Address and Node IPv6 
Local Address sub-TLVs of the Node Attribute TLV for a router to advertise additional local IPv4 
and IPv6 addresses. However, [RFC5786] did not describe the advertisement and usage of these 
sub-TLVs when the address family of the advertised local address differed from the address 
family of the OSPF traffic engineering protocol. 


This document updates [RFC5786] so that a router can also announce one or more local X-AF 

addresses using the corresponding Local Address sub-TLV. Routers using the Node Attribute TLV 
[RFC5786] can include non-TE-enabled interface addresses in their OSPF TE advertisements and 
also use the same sub-TLVs to carry X-AF information, facilitating the mapping described above. 


The method specified in this document can also be used to compute the X-AF mapping of the 
egress Label Switching Router (LSR) for sub-LSPs of a Point-to-Multipoint LSP [RFC4461]. 
Considerations of using Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside the 
scope of this document. 


2. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 
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3. Operation 


To implement the X-AF routing technique described in this document, OSPFv2 will advertise the 
Node IPv6 Local Address sub-TLV and OSPFv3 will advertise the Node IPv4 Local Address sub- 
TLY, possibly in addition to advertising other IP addresses as documented by [RFC5786]. 


Multiple instances of OSPFv3 are needed if it is used for both IPv4 and IPv6 [RFC5838]. The 
operation in this section is described with OSPFv2 as the protocol used for IPv4; that is the most 
common case. The case of OSPFv3 being used for IPv4 follows the same procedure as what is 
indicated for OSPFv2 below. 


On a node that implements X-AF routing, each OSPF instance advertises, using the Node Local 
Address sub-TLV, all X-AF IPv6 (for OSPFv2 instance) or IPv4 (for OSPFv3) addresses local to the 
router that can be used by the Constrained Shortest Path First (CSPF) to calculate MPLS TE LSPs: 


e The OSPF instance MUST advertise the IP address listed in the Router Address TLV [RFC3630] 
[RFC5329] of the X-AF instance maintaining the TE database. 

e The OSPF instance SHOULD include additional local addresses advertised by the X-AF OSPF 
instance in its Node Local Address sub-TLVs. 


e An implementation MAY advertise other local X-AF addresses. 


When TE information is advertised in an OSPF instance, both natively (i.e., as per RFC [RFC3630] 
or [RFC5329]) and as X-AF Node Attribute TLV, it is left to local configuration to determine which 
TE database is used to compute routes for the OSPF instance. 


On Area Border Routers (ABRs), each advertised X-AF IP address MUST be advertised into, at 
most, one area. If OSPFv2 and OSPFv3 ABRs coincide (i.e., the areas for all OSPFv2 and OSPFv3 
interfaces are the same), then the X-AF addresses MUST be advertised into the same area in both 
instances. This allows other ABRs connected to the same set of areas to know with which area to 
associate computed MPLS TE tunnels. 


During the X-AF routing calculation, X-AF IP addresses are used to map locally created LSPs to 
tail-end routers in the LSDB. The mapping algorithm can be described as: 


Walk the list of all MPLS TE tunnels for which the computing router is a head end. For each 
MPLS TE tunnel T: 


1. If T's destination address is from the same address family as the OSPF instance associated 
with the LSDB, then the extensions defined in this document do not apply. 


2. Otherwise, it is a X-AF MPLS TE tunnel. Note the tunnel's destination IP address. 


3. Walk the X-AF IP addresses in the LSDBs of all connected areas. If a matching IP address is 
found, advertised by router R in area A, then mark the tunnel T as belonging to area A and 
terminating on tail-end router R. Assign the intra-area SPF cost to reach router R within 
area A as the IGP cost of tunnel T. 


After completing this calculation, each TE tunnel is associated with an area and tail-end router in 
terms of the routing LSDB of the computing OSPF instance and has a cost. 
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The algorithm described above is to be used only if the Node Local Address sub-TLV includes X- 
AF information. 


Note that, for clarity of description, the mapping algorithm is specified as a single calculation. 
Implementations may choose to support equivalent mapping functionality without 
implementing the algorithm as described. 


As an example, consider a router in a dual-stack network using OSPFv2 and OSPFv3 for IPv4 and 
IPv6 routing, respectively. Suppose the OSPFv2 instance is used to propagate MPLS TE 
information and the router is configured to accept TE LSPs terminating at local addresses 
198.51.100.1 and 198.51.100.2. The router advertises in OSPFv2 the IPv4 address 198.51.100.1 in 
the Router Address TLV, the additional local IPv4 address 198.51.100.2 in the Node IPv4 Local 
Address sub-TLV, and other TE TLVs as required by [RFC3630]. If the OSPFV3 instance in the 
network is enabled for X-AF TE routing (that is, to use MPLS TE LSPs computed by OSPFv2 for 
IPv6 routing), then the OSPFv3 instance of the router will advertise the Node IPv4 Local Address 
sub-TLV listing the local IPv4 addresses 198.51.100.1 and 198.51.100.2. Other routers in the 
OSPFv3 network will use this information to reliably identify this router as the egress LSR for 
MPLS TE LSPs terminating at either 198.51.100.1 or 198.51.100.2. 


4. Backward Compatibility 


Only routers that serve as endpoints for one or more TE tunnels MUST be upgraded to support 
the procedures described herein: 


e Tunnel tail-end routers advertise the Node IPv4 Local Address sub-TLV and/or the Node IPv6 
Local Address sub-TLV. 


¢ Tunnel head-end routers perform the X-AF routing calculation. 


Both the endpoints MUST be upgraded before the tail end starts advertising the X-AF information. 
Other routers in the network do not need to support X-AF procedures. 


4.1. Automatically Switched Optical Networks 


[RFC6827] updates [RFC5786] by defining extensions to be used in an Automatically Switched 
Optical Network (ASON). The Local TE Router ID sub-TLV is required for determining ASON 
reachability. The implication is that if the Local TE Router ID sub-TLV is present in the Node 
Attribute TLV, then the procedures in [RFC6827] apply, regardless of whether any X-AF 
information is advertised. 


5. Security Considerations 


This document describes the use of the Local Address sub-TLVs to provide X-AF information. The 
advertisement of these sub-TLVs, in any OSPF instance, is not precluded by [RFC5786]. As such, 
no new security threats are introduced beyond the considerations in OSPFv2 [RFC2328], OSPF v3 
[RFC5340], and [RFC5786]. 
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The X-AF information is not used for SPF computation or normal routing, so the mechanism 
specified here has no effect on IP routing. However, generating incorrect information or 
tampering with the sub-TLVs may have an effect on traffic engineering computations. 
Specifically, TE traffic may be delivered to the wrong tail-end router, which could lead to 
suboptimal routing, traffic loops, or exposing the traffic to attacker inspection or modification. 
These threats are already present in other TE-related specifications, and their considerations 
apply here as well, including [RFC3630] and [RFC5329]. 


6. IANA Considerations 


This document has no IANA actions. 
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